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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the Diameter-based interfaces specific to SMS when they are used in conjunction with 
the "SMS in MME" architecture specified in 3GPP TS 23.272 [2]. It comprises: 

- the Diameter apphcation for the S6c interface between the HSS and the SMS-GMSC or the SMS Router and 
between the SMS-GMSC and the SMS Router; 

- the Diameter apphcation for the SGd interface between the MME and the SMS-IWMSC or the SMS-GMSC or 
the SMS Router and between the SMS-GMSC and the SMS Router. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

For a specific reference, subsequent revisions do not apply. 

For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.272: "Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2". 

[3] 3GPP TS 23.040: "Technical reahzation of the Short Message Service (SMS)". 

[4] 3GPP TS 29.272: "Evolved Packet System (EPS); Mobility Management Entity (MME) and 

Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol". 

[5] 3GPP TS 29.229: "Cx and Dx interfaces based on the Diameter protocol; Protocol details". 

[6] IETF RFC 2234: "Augmented BNF for Syntax Specifications: ABNF". 

[7] IETF RFC 3588: "Diameter Base Protocol". 

[8] IETF RFC 5516: "Diameter Command Code Registration for the Third Generation Partnership 

Project (3GPP) Evolved Packet System (EPS)". 

[9] 3GPP TS 29.002: "Mobile Application Part (MAP) specification". 

[10] 3GPP TS 29.173: "Location Services (LCS); Diameter-based SLh interface for Control Plane 

LCS". 

[II] 3GPP TS 33.210: "3G security; Network Domain Security (NDS); IP network layer security ". 
[12] IETF RFC 4960: "Stream Control Transport Protocol". 

[13] ITU-T Recommendation E.164: "The international public telecommunication numbering plan". 

[14] 3GPP TS 29.329: "Sh Interface based on the Diameter protocol; Protocol details". 

[15] 3GPP TS 29.336: "Home Subscriber Server (HSS) diameter interfaces for interworking with 

packet data networks and applications". 

[16] 3GPP TS 23.003: "Numbering, addressing and idenfification". 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

ABNF Augmented Backus-Naur Form 

lANA Internet Assigned Numbers Authority 

IP-SM-GW IP Short Message Gateway 

MWD Message Waiting Data 

RP Relay layer Protocol 

RP-MTI RP Message Type Indicator 

RP-SMEA RP SME-Address 

RP-Ul RP User Information 

SM RL Short Message Relay Layer 

SMS-GMSC Gateway MSC for SMS 

SMS-IWMSC Interworking MSC for SMS 



4 General 

4.1 Introduction 

The SMS in MME architecture is described in 3GPP TS 23.272 [2] and has specified the reference points S6c and SGd. 
The clause 4 addresses Diameter aspects which are common to both S6c and SGd. 

4.2 Use of Diameter Base protocol 

The Diameter Base Protocol as specified in IETF RFC 3588 [7] shall apply except as modified by the defined support 
of the methods and the defined support of the commands and AVPs, result and error codes as specified in this 
specification. Unless otherwise specified, the procedures (including error handling and unrecognised information 
handling) shall be used unmodified. 

4.3 Securing Diameter messages 

For secure transport of Diameter messages, see 3GPP TS 33.210 [11]. 



4.4 Accounting functionality 



Accounting functionality (Accounting Session State Machine, related command codes and AVPs) shall not be used on 
the S6c and SGd interfaces. 
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4.5 Use of sessions 

Between the MME or the HSS and the SMS-IWMSC or the SMS-GMSC or the SMS Router and between the SMS- 
GMSC and the SMS Router, Diameter sessions shall be implicitly terminated. An implicitly terminated session is one 
for which the server does not maintain state information. The client shall not send any re-authorization or session 
termination requests to the server. 

The Diameter base protocol includes the Auth-Session-State AVP as the mechanism for the implementation of 
implicitly terminated sessions. 

The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value 
NO_STATE_MAINTAINED (1), as described in IETF RFC 3588 [7]. As a consequence, the server shall not maintain 
any state information about this session and the client shall not send any session termination request. Neither the 
Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses. 



4.6 Transport protocol 



Diameter messages over the S6c and SGd interfaces shall make use of SCTP as specified in IETF RFC 4960 [12] as 
transport protocol. 



4.7 Advertising application support 



The MME, HSS, SMS-IWMSC, SMS-GMSC and SMS Router shall advertise support of the Diameter S6c and/or SGd 
Application by including the value of the application identifier in the Auth- Application-Id AVP within the Vendor- 
Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange- Answer 
commands. 

The vendor identifier value of 3GPP (10415) shall be included in the Supported- Vendor-Id AVP of the Capabilities- 
Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor- 
Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange- Answer 
commands. 

The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange- Answer commands that is 
not included in the Vendor-Specific-Application-Id AVPs as described above shall indicate the manufacturer of the 
Diameter node as per IETF RFC 3588 [7]. 



4.8 Diameter Application Identifier 



The S6c and SGd interface protocols shall be defined, each, as an IETF vendor specific Diameter application, where the 
vendor is 3GPP. The vendor identifier assigned by lANA to 3GPP (http://www.iana.org/assignments/enterprise- 
numbers) is 10415. 

The Diameter application identifier assigned to the S6c interface application is 16777312 (allocated by IAN A). 

The Diameter application identifier assigned to the SGd interface application is 16777313 (allocated by lANA). 

4.9 Use of the Supported-Features AVP 

When new functionality is introduced on the S6c or SGd applications, it should be defined as optional. If backwards 
incompatible changes can not be avoided, the new functionality shall be introduced as a new feature and support 
advertised with the Supported-Features AVP. The usage of the Supported-Features AVP on the S6c or S6e applications 
is consistent with the procedures for the dynamic discovery of supported features as defined in clause 7.2 of 3GPP TS 
29.229 [5]. 

When extending the application by adding new AVPs for a feature, the new AVPs shall have the M bit cleared and the 
AVP shall not be defined mandatory in the command ABNF. 

As defined in 3GPP TS 29.229 [5], the Supported-Features AVP is of type grouped and contains the Vendor-Id, 
Feature-List-ID and Feature-List AVPs. On the all reference points as specified in this specification, the Supported- 
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Features AVP is used to identify features that have been defined by 3GPP and hence, for features defined in this 
document, the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple feature lists defined 
for the reference point, the Feature-List-ID AVP shall differentiate those lists from one another. 



5 Diameter based S6c interface between HSS and 

central SIVIS functions 

5.1 Introduction 

The S6c interface enables the retrieval of routing information for the transfer of short messages, the report of status of 
the delivery status of a short message and the alerting of the SMS-SC between the HSS, the SMS-GMSC and the SMS 
Router as described in 3GPP TS 23.040 [3]. 

5.2 Procedures description 

5.2.1 Send Routing Info for SM procedure 
5.2.1.1 General 

This procedure shall be used between the SMS-GMSC or the IP-SM-GW and the HSS to retrieve the routing 
information needed for routing the short message to the serving MSC or MME or SGSN. This procedure is also used 
between the SMS-GMSC and the SMS Router or the IP-SM-GW, and between the HSS and the SMS Router or the IP- 
SM-GW in order to enforce routing of the SM delivery via the HPLMN of the receiving MS. 

This procedure is applicable to an IP-SM-GW for its SMS Router function when using the S6c interface. 

This procedure is used according to the call flows described in 3GPP TS 23.040 [2] clause 10. 

Table 5.2.1.1-1 specifies the involved information elements for the request. 

Table 5.2.1.1-2 specifies the involved information elements for the answer. 

This procedure is mapped to the commands Send-Routing-Info-for-SM-Request/ Answer (SRR/SRA) in the Diameter 
application specified in subclause 5.3.2. 
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Table 5.2.1.1-1 : Send Routing Info for SM Request 



Information 

element 

name 


Mapping to 
Diameter AVP 


Cat. 


Description 


MSISDN 


MSISDN 


C 


This information element shall be present when the MSISDN exists and 
shall contain the MSISDN of the user. 


IMSI 


User-Name 
(See IETF 
RFC 3588 [6]) 


c 


This information element shall be present when the MSISDN does not 
exist and shall contain the IMSI of the user. 


Service 

Centre 

Address 


SC-Address 


M 


This information element shall contain the Service Centre address. 


SM-RP-MTI 


SM-RP-MTI 


C 


This information element shall contain the RP-Message Type Indicator of 
the Short Message. It is used to distinguish a SM sent to the mobile station 
in order to acknowledge an MO-SM initiated by the mobile from a normal 
MT-SM. This information element is formatted according to the formatting 
rules of address fields as described in 3GPP TS 23.040 [2]. 


SM-RP- 
SMEA 


SM-RP-SMEA 


c 


This information element shall contain the RP-Originating SME-address of 
the Short Message Entity that has originated the SM. This information 
element shall be present if the SMS-GMSC supports receiving of the two 
numbers from the HSS. Used by the short message service relay sub- 
layer protocol it shall be formatted according to the formatting rules of 
address fields as described in 3GPP TS 23 040 [2]. 


SRR Flags 


SRR-Flags 


c 


This Information Element contains a bit mask. See 5.3.3.4 for the meaning 
of the bits and the condition for each bit to be set or not. 


SIVI-Delivery 
Not Intended 


SM-Delivery 
Not Intended 





This information element, when present, shall indicate that delivery of a 
short message is not intended. It further indicates whether only IMSI or 
only MCC-i-MNC are requested. 

This information element may be set by entities that request the service 
without intending to deliver a short message, and shall be evaluated by the 
SMS Router and may be evaluated by the HLR. 


Supported 
Features 


Supported- 
Features 
(See 3GPP TS 
29.229 [5]) 





If present, this Information Element shall contain the list of features 
supported by the origin host. 
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Table 5.2.1.1-2: Send Routing Info for SM Answer 



Information 

element 

name 


Mapping to 
Diameter AVP 


Cat. 


Description 


Result 


Result-Code / 
Experimental- 
Result 


M 


Result of the request. 

Result-Code AVP shall be used for errors defined in the Diameter Base 

Protocol. 

Experimental-Result AVP shall be used for S6c errors. This is a grouped 

AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the 

error code in the Experimental-Result-Code AVP. This information element 

shall contain the result of the operation with an indication of the success / 

errors. 

The following errors are applicable in this case: 

Unknown User; 

Service Barred; 

Teleservice Not Provisioned; 

Absent User; 

Facility Not Supported. 


IMS! 


User-Name 
(See IETF 
RFC 3588 [6]) 


C 


This information element: 

either shall contain the IMSI of the user. 

or, if enforcement of routing an SM via the HPLMN of the 

receiving MS or UE is deployed, shall contain an MT Correlation 

ID instead of an IMSI when the service is used between SMS- 

GMSC and SMS Router (see 3GPP TS 23.040 [3] for more 

information). 

or, if the "SM-Delivery Not Intended" Information Element was 

present in the request with a value of "only MCC-i-MNC 

requested", may contain MCC-i-MNC-Hdummy MSIN. 

This information element shall be present in a successful answer. 

This information element shall be present in an answer from the HSS to 

the IP-SM-GW, if an Absent User result is returned and the UNRI is not 

set. 


Serving-Node 


Serving-Node 


C 


If the "SM-Delivery Not Intended" Information Element was not present in 
the request, this information element shall contain the identity of one 
serving node on which the user is registered. This identity shall either be: 

the Diameter identity and the Diameter realm of the MME 

registered for MT SMS plus the El 64 number of the MME for MT 

SMS. 

or the ISDN number of the MSC 

or the ISDN number of the SGSN, 
If the "SM-Delivery Not Intended" Information Element was present in the 
request, this information element may be absent. 
This information element shall be present in a successful answer. 


LMSI 


LMSI 


c 


The HSS shall include the LMSI in a successful response, if the VLR has 
used the LMSI and if there is the ISDN number of an MSC in the answer. 


Additional 
Serving Node 


Additional- 
Serving-Node 


c 


This information element, when present shall either contain: 

the Diameter identity and the Diameter realm of the MME 

registered for MT SIVIS plus the El 64 number of the MME for MT 

SMS. 

or the ISDN number of the MSC 

or the ISDN number of the SGSN. 

It shall not contain information delivered in the Serving Node information 

element. 


User Identifier 
Alert 


User-Identifier 


c 


This information element shall contain the MSISDN stored in the HSS, 
when available. 


MWD Status 


MWD-Status 


c 


This Information Element is sent when appropriate and shall contain a bit 
mask. See 5.3.3.8 for the meaning of the bits. 


IVIME Absent 
User 

Diagnostic 
SM 


MME-Absent- 

User- 

Diagnostic-SM 


c 


This information element shall contain the reason of the absence of the 
user when given by the MME and stored in the HSS 


MSC Absent 
User 

Diagnostic 
SM 


MSC-Absent- 

User- 

Diagnostic-SM 


c 


This information element shall contain the reason of the absence of the 
user when given by the MSC and stored in the HSS 
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SGSN Absent 
User 

Diagnostic 
SM 


SGSN-Absent- 

User- 

Diagnostic-SIVI 


C 


This information element shall contain the reason of the absence of the 
user when given by the SGSN and stored in the HSS 


Supported 
Features 


Supported- 
Features 
(See 3GPP 
TS 29.229 [5]) 





If present, this information element shall contain the list of features 
supported by the origin host. 



5.2.1.2 



Detailed behaviour of the SMS-GMSC 



The SMS-GMSC shall make use of this procedure to retrieve the routing information needed for routing the short 
message to the serving MSC or MME or SGSN or for enforcing routing of the SM delivery via the SMS Router of 
HPLMN. 

It shall populate the information elements in the Send Routing Info for SM request according to the table 5.2.1.1-1. 

When receiving the Send Routing Info for-SM Answer, the SMS-GMSC or the SMS Router shall use the received 
Diameter address if the SMS-GMSC or the SMS Router transfers the terminating short message over the SGd interface. 



5.2.1.3 



Detailed behaviour of the HSS 



This subclause describes the HSS behaviour when the HSS receives a Send Routing Info for SM request which is not 
forwarded to an SMS Router or an IP-SM-GW. 

The HSS shall check if the user identified by the MSISDN is known; otherwise the HSS shall return an Experimental- 
Result-Code set to DIAMETER_ERROR_USER_UNKNOWN. 

The HSS shall check if a MT SMS Teleservice subscription exists; otherwise the HSS shall return an Experimental- 
Result-Code set to DIAMETER_ERROR_SERVICE_NOT_SUBSCRIBED. 

The HSS shall check if the user is not barred for receiving MT short messages; otherwise, the HSS shall return an 
Experimental-Result-Code set to DIAMETER. SERVICE _ERROR_BARRED. 

The HSS shall check if one or more serving nodes are registered for MT SMS; otherwise, the HSS shall return an 
Experimental-Result-Code set to DIAMETER_ERROR_ABSENT_USER. 

The HSS shall then return a Send Routing Info for SM answer with a Result-Code set to DIAMETER_SUCCESSFUL 
that shall contain the addresses of the serving nodes which are registered for MT SMS according the following rules: 

if the GPRS indicator is not set, only one serving node address shall be returned according to the SM transfer 
option where MME is considered as a MSC. The address of the MME, if returned, shall comprise the MME 
Diameter address and the MME Number for MT SMS. 

- if the GPRS indicator is set, two serving node addresses shall be returned of which 

- the SGSN number, 

- either the number of the MSC or the Diameter address and the number of the MME for MT SMS. 

when two serving g nodes addresses are returned, the HSS selects which serving node it will populate in the 
Serving Node information element and in the Additional Serving Node information elements. 

NOTE: MSC and MME cannot be both registered as serving nodes for MT SMS at a given time (cf 3GPP TS 
23.272 [2]) 

If the stored MSISDN number is not the same as the one received in the Send Routing Info for SM request service, the 
stored MSISDN number shall be included in the message. 

5.2.1 .4 Detailed behaviour of the SMS Router 

When receiving a Send Routing Info for SM request, the SMS Router shall: 
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send a Send Routing Info for SM request to the HSS to retrieve the routing information needed for routing the 
short message to the serving MSC or MME or SGSN; 

if the Send Routing Info for SM answer received from HSS is successful, the SMS Router shall send a Send 
Routing Info for SM answer to the SMS-GMSC where 

the SMS router shall populate the same Serving Node and Additional Serving Node fields (i.e AVPs) as the 
ones it received in the Send Routing Info for SM answer from HSS, but with its own SMS Router number 
and its own SMS Router Diameter address; 

if the Send Routing Info for SM answer received from HSS is not successful, the SMS Router shall send a Send 
Routing Info for SM answer to the SMS-GMSC with the same Diameter error result code. 

If the SMS Router receives some of the following information elements. User Identifier Alert, MWD Status, MSC 
Absent User Diagnostic SM, MME Absent User Diagnostic SM, SGSN Absent User Diagnostic SM, it shall transfer 
them in the Send-Routing Info for SM answer to the SMS-GMSC. 



5.2.2 Alert Service Centre procedure 



5.2.2.1 



General 



This procedure shall be used between the HSS and the SMS-IWMSC to indicate that the MS is now recognized by the 
PLMN to have recovered its operation to allow for an MT SMS delivery. This procedure is used according to the call 
flows described in 3GPP TS 23.040 [2] clause 10. 

Table 5.2.2.1-1 specifies the involved information elements for the request. 

Table 5.2.2.1-2 specifies the involved information elements for the answer. 

This procedure is mapped to the commands Alert-Service-Centre-Request/ Answer (ALR/ALA) in the Diameter 
application specified in subclause 5.3.2. 

Table 5.2.2.1-1 : Alert Service Centre Request 



Information 

element 

name 


Mapping to 
Diameter AVP 


Cat. 


Description 


Service 

Centre 

Address 


SC-Address 


M 


This information element shall contain the Service Centre address 
received from the mobile station. 


User Identifier 
Alert 


User-Identifier 


M 


This information element shall contain 

the Alert MSISDN when it exists 
otherwise the IMSI. 


Supported 
Features 


Supported- 
Features 
(See 3GPP TS 
29.229 [5]) 





If present, this information element shall contain the list of features 
supported by the origin host. 
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Table 5.2.2.1-2: Alert Service Centre Answer 



Information 

element 

name 


Mapping to 
Diameter AVP 


Cat. 


Description 


Result 


Result-Code / 
Experimental- 
Result 


M 


This information element shall contain the result of the request. 

The Result-Code AVP shall be used for errors defined in the Diameter 

Base Protocol. 

The Experimental-Result AVP shall be used for S6c errors. This is a 

grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, 

and the error code in the Experimental-Result-Code AVP. This information 

element shall contain the result of the operation with an indication of the 

success / errors. No errors are defined for this case. 


Supported 
Features 


Supported- 
Features 
(See 3GPP 
TS 29.229 [5]) 





If present, this information element shall contain the list of features 
supported by the origin host. 



5.2.2.2 



Detailed behaviour of the HSS 



The HSS shall make use of this procedure to alert the service centre when the mobile user is active after a short message 
transfer has failed because the mobile user is not reachable, or when the UE has indicated that it has memory capacity to 
accept a short message. 

It is an operator option to resend an Alert Service Centre request to the SMS-IWMSC if the alert is unsuccessful. The 
number of repeat attempts and the interval between them is also an operator option. The service centre address should 
be purged from the MWD list if the alert is consistently unsuccessful. 



5.2.2.3 



Detailed behaviour of the SMS-IWMSC 



When receiving an Alert Service Centre request the SMS-IWMSC shall check whether the service centre address is 
known. If the service centre address is not valid, then no further action shall be taken. 

If the service centre address is valid, the SMS-IW-MSC generates an Alert Service Centre message towards the SMS 
Centre. 

5.2.3 Report SM Delivery Status procedure 



5.2.3.1 



General 



This procedure shall be used between the SMS-GMSC or the IP-SM-GW and the HSS to update the Message Waiting 
Data in the HSS or to inform the HSS of a successful SM transfer after polling. This procedure is invoked by the SMS- 
GMSC or the IP-SM-GW. 

This procedure is applicable to an IP-SM-GW for its SMS Router function when using the S6c interface. 

This procedure is used according to the call flows described in 3GPP TS 23.040 [2] clause 10. 

Table 5.2.3.1-1 specifies the involved information elements for the request. 

Table 5.2.3.1-2 specifies the involved information elements for the answer. 

This procedure is mapped to the commands Report-SM-Delivery-Status-Request/ Answer (RDR/RDA) in the Diameter 
application specified in subclause 5.3.2. 
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Table 5.2.3.1-1 : Report SM Delivery Status Request 



Information 

element 

name 


Mapping to 
Diameter AVP 


Cat. 


Description 


MSISDN 


User-Identifier 


M 


This information element shall contain the IVISISDN of the user when it 
exists. Otherwise It shall contain the IMSI (i.e. when the user has a 
IVISISDN-less subscription). 


Service 

Centre 

Address 


SC-Address 


M 


This information element shall contain the Service Centre address. 


SIVI Delivery 
Outcome 


SM-Delivery- 
Outcome 


M 


This information element shall contain the causes for setting the message 
waiting data in the HSS according to the network node(s) used for the SM 
delivery: 

- MSC 

- MME 

- SGSN 

- IP-SM-GW. 

At least one cause shall be present. A cause originated from a MSC and a 
cause originated from a MME shall not be both present. 
When the cause is Absent User, the Absent User Diagnostic, if available, 
shall be associated to the cause. 


Supported 
Features 


Supported- 
Features 
(See 3GPP TS 
29.229 [5]) 





If present, this Information Element shall contain the list of features 
supported by the origin host. 



Table 5.2.3.1-2: Report SM Delivery Status Answer 



Information 

element 

name 


Mapping to 
Diameter AVP 


Cat. 


Description 


Result 


Result-Code / 
Experimental- 
Result 


M 


This information element shall contain the Result of the request. 

The Result-Code AVP shall be used for errors defined in the Diameter 

Base Protocol. 

The Experimental-Result AVP shall be used for S6c errors. This is a 

grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, 

and the error code in the Experimental-Result-Code AVP. This information 

element shall contain the result of the operation with an indication of the 

success / errors. The following errors are applicable: 

- Unknown User; 

- Message Waiting List Full. 


MSISDN- 
Alert 


User-Identifier 


C 


This information element shall contain the Alert MSISDN of the user if it is 
different from the MSISDN received in the request. 


Supported 
Features 


Supported- 
Features 
(See 3GPP 
TS 29.229 [5]) 





If present, this information element shall contain the list of features 
supported by the origin host. 



5.2.3.2 



Detailed behaviour of the SMS-GMSC 



The SMS-GMSC shall make use of this procedure if: 

the reason received from the serving node for failure to deliver the message is absent user , unidentified user or 
SM delivery failure with error cause "UE memory capacity exceeded", and the SC address is not yet included in 
the MVV'D set, or 

the reason received from the serving node for failure to deliver the message is absent user, unidentified user or 
SM delivery failure with error cause "UE memory capacity exceeded", and the corresponding flag in the HSS (as 
indicated in the information received from HSS) is not set, or 

the reason received from the serving node (MSC/MME or SGSN) for failure to deliver the message is absent 
user and the absent user diagnostic is different from the absent user diagnostic received from the HSS. 
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If absent user diagnostic information (see 3GPP TS 23.040 [3]) is received with the absent user error indication then the 
SMS-GMSC shall relay this information to the HSS. 

5.2.3.3 Detailed behaviour of IP-SM-GW 

The IP-SM-GW shall make use of this procedure if: 

the reason for failure to deliver the message is absent user, unidentified user or SM delivery failure with error 
cause "UE memory capacity exceeded", and the SC address is not yet included in the MWD set, or 

the reason for failure to deliver the message is absent user, unidentified user or SM delivery failure with error 
cause "UE memory capacity exceeded", and the corresponding flag in the HSS (as indicated in the information 
received in the MAP_INFORM_SERVICE_CENTRE) is not set, or 

the reason for failure to deliver the message is absent user and the absent user diagnostic is different from the 
absent user diagnostic received from the HSS. 

5.2.3.4 Detailed behaviour of the HSS 

When receiving a Report SM Delivery Status request the HSS shall check if the user is known. 

If the user is not known, the HSS shall return an Experimental-Result-Code set to 
DIAMETER_ERROR_USER_UNKNOWN. 

If it is known, the HSS shall update the Message Waiting data as described in 3GPP TS 23.040 [3]. If the message 
waiting data is full, the HSS shall return an Experimental -Result-Code set to 
DIAMETER_ERROR_MWD_LIST_FULL. 

If the received MSISDN is different from the stored MSISDN, the HSS shall return the Alert MSISDN. 

5.3 Protocol specification 

5.3.1 Routing considerations 

5.3.1 .1 Requests from the SMS-GMSC or the SMS router 

5.3.1.1.1 Introduction 

The subclauses in 5.3.1.1 specify the use of the Diameter routing AVPs Destination-Realm and Destination-Host over 
the S6c interface for Diameter command requests from the SMS-GMSC or the SMS router (i.e. for the Send Routing 
Info for SM and the Report SM Delivery Status procedures). 

5.3.1 .1 .2 Routing from the originating PLMN 

If the SMS-GMSC or the SMS router has stored or can obtain the address/name and the home network domain name of 
the HSS identified by the MSISDN or the IMSI, both the Destination-Realm and Destination-Host AVPs shall be 
present in the request. 

The SMS Router shall use the MCC/MNC values of the PLMN to which it belongs, to build the MCC/MNC based 
network domain as described in subclause 19.2 of 3GPP TS 23.003 [16] and include it in the Destination-Realm AVP of 
the request. The request shall then be routed to the next Diameter node. 

If the SMS-GMSC can only obtain the MCC/MNC values from the MSISDN or the IMSI, the SMS-GMSC shall use 
them to build the MCC/MNC based network domain as described in subclause 19.2 of 3GPP TS 23.003 [16] and 
include it in the Destination-Realm AVP of the request. The request shall then be routed to the next Diameter node. 

If the SMS-GMSC cannot obtain the MCC/MNC values from the MSISDN of the user, the SMS-GMSC may forward 
the request to a Diameter node within the same PLMN, the Destination Realm content being left to the PLMN operator 
choice. Then: 
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if a Diameter node in the routing path insides the PLMN of the SMS-GSMC can obtain the MCC/MNC values 
of the PLMN to which the user is subscribed to (i.e. when the number portabiHty is resolved in the network of 
the SMS-GMSC), or 

if, otherwise, the Diameter node can obtain the MCC/MNC values of the PLMN associated to the CC and NDC 
codes of the MSISDN of the user, then 

the Diameter node shall use them to build the MCC/MNC based network domain as described in subclause 19.2 
of 3GPP TS 23.003 [16] and include it in the Destination-Realm AVP of the request. The request shall then be 
routed to the next Diameter node. 

If the MCC/MNC values of the PLMN associated to the CC and NDC codes of the MSISDN or the MCC/MNC values 
of the PLMN to which the user is subscribed to cannot be obtained in the PLMN of the SMS-GMSC, the request shall 
be replaced in the PLMN of the SMS-GMSC by an equivalent request routed through a MAP interface (e.g. via an 
IWF). 

NOTE 1 : The inter PLMN routing principle is to reuse the routing based on a MCC/MNC based domain name as 
used by other Diameter applications such as S6a/d. It is assumed that obtaining the relevant MCC/MNC 
values from the MSISDN can be achieved in the PLMN to which the SMS-GMSC belongs. Otherwise 
MAP based routing is used. This routing principle may be completed with other routing solutions in the 
future. 

NOTE 2: The Number portability resolution in the PLMN of the SMS-GMSC can be handled by an intermediate 

Diameter agent consulting a Number Portability Database of the Network Portability domain to which the 
PLMN of the SMS-GMSC belongs. 

5.3.1 .1 .3 Routing in the HPLMN 

When the request reaches a Diameter node in the home PLMN of the user and when multiple and separately addressable 
HSSs have been deployed in the home PLMN, the identity of the HSS that holds the subscriber data for a given user 
identified by its MSISDN may be retrieved by a user identity to HSS resolution mechanism as described in subclause 
5.4. 

Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by an SMS- 
GMSC or a SMS Router. 

The HSS, when receiving a Send Routing Info for SM request, checks if an SMS Router is configured in the home 
network or if an IP-SM-GW has been registered for the user. If yes, the HSS shall act as a Diameter proxy and forward 
the request to the SMS Router or to the IP-SM-GW, by inserting the Diameter address of the SMS Router or of the IP- 
SM-GW as the Diameter destination address. 

If the Vendor-Specific- Application-ID AVP is received in any of the commands, it may be ignored by the receiving 
node, and it shall not be used for routing purposes. 

5.3.1 .2 Requests from the HSS 

This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host over the S6c 
interface for Diameter command requests from the HSS (i.e. for the Alert SC procedure). 

If the HSS has stored the address/name of the SMS-SC and the associated home network domain name in the Message 
Waiting Data of the user, both the Destination-Realm and Destination-Host AVPs shall be present in the Diameter 
request. Otherwise the routing shall use MAP. 

5.3.2 Commands 
5.3.2.1 Introduction 

This section defines the Command code values and related ABNF for each command described for the S6c interface. 
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5.3.2.2 



Command-Code values 



This section defines the Command-Code values for the S6c interface application as allocated by lANA in the IETF RFC 

5516 [8]. 

Every command is defined by means of the ABNF syntax IETF RFC 2234 [6], according to the rules in IETF RFC 
3588 [7]. In the case, the definition and use of an AVP is not specified in this document, the guidelines in IETF RFC 
3588 [7] shall apply. 

NOTE: For this release, the Vendor-Specific-Application-ID is included as an optional AVP in all commands in 
order to ensure interoperability with diameter agents following a strict implementation of IETF RFC 3588 
[7], by which messages not including this AVP will be rejected. IETF RFC 3588 [7] indicates that the 
AVP shall be present in all proxiable commands, such as those specified here, despite that the contents of 
this AVP are redundant since the Application ID is already present in the command header. This AVP 
may be removed in subsequent revisions of this specification, once the diameter base protocol is updated 
accordingly. 

The following Command Codes are defined in this specification: 

Table 5.3.2.2/1 : Command-Code values for S6c 



Command-Name 


Abbreviation 


Code 


Section 


Send-Routing-lnfo-for-SM-Request 


SRR 


8388647 


5.3.2.3 


Send-Routing-lnfo-for-SM-Answer 


SRA 


8388647 


5.3.2.4 


Alert-Service-Centre-Request 


ALR 


8388648 


5.3.2.5 


Alert-Service-Centre-Answer 


ALA 


8388648 


5.3.2.6 


Report-SIVI-Delivery-Status-Request 


RDR 


8388649 


5.3.2.7 


Report-SM-Delivery-Status-Answer 


RDA 


8388649 


5.3.2.8 



For these commands, the Application-ID field shall be set to 16777312 (application identifier of the S6c interface 
application allocated by lANA). 



5.3.2.3 



Send-Routing-lnfo-for-SM-Request (SRR) Command 



The Send-Routing-Info-for-SM-Request (SRR) command, indicated by the Command-Code field set to 8388647 and 
the "R" bit set in the Command Flags field, is sent from SMS-GMSC to HSS or SMS Router or from SMS Router to 
HSS. 

Message Format: 

< Send-Routing-Info-for-SM-Request > ::= < Diameter Header: 8388647, REQ, PXY, 16777312 > 

< Session-Id > 

[ Vendor-Specific-Application-Id ] 
{ Auth-Session-State } 
{ Origin-Host } 
{ Origin-Realm } 
[ Destination-Host ] 
{ Destination-Realm } 
[ MSISDN ] 
[ User-Name ] 
*[ Supported-Features ] 
[ SC-Address ] 
[ SM-RP-MTI ] 
[ SM-RP-SMEA ] 
[ SRR-Flags ] 

[ SM-Delivery-Not-Intended ] 
*[ AVP ] 
*[ Proxy -Info ] 
*[ Route-Record ] 



£75/ 



3GPP TS 29.338 version 1 1 .0.0 Release 1 1 20 ETSI TS 1 29 338 V1 1 .0.0 (201 3-01 ) 

5.3.2.4 Send-Routing-info-for-SM-Answer (SRA) Command 

The Send-Routing-Info-for-SM- Answer command (SRA) command, indicated by the Command-Code field set to 
8388647 and the 'R' bit cleared in the Command Flags field, is sent from HSS to SMS-GMSC or SMS Router or from 
SMS Router to SMS-GMSC. 

Message Format 

< Send-Routing-info-for-SM-Answer > ::= < Diameter Header: 8388647, PXY, 16777312 > 

< Session-Id > 

[ Vendor-Specific-Application-Id ] 

[ Result-Code ] 

[ Experimental-Result ] 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 

[ User-Name ] 

*[ Supported-Features ] 

[ Serving-Node ] 

[ Additional-Serving-Node ] 

[ LMSI ] 

[ User-Identifier ] 

[ MWD-Status ] 

[ MME-Absent-User-Diagnostic-SM ] 

[ MSC-Absent-User-Diagnostic-SM ] 

[ SGSN-Absent-User-Diagnostic-SM ] 

*[ AVP ] 

*[ Failed- AVP ] 

*[ Proxy-Info ] 

*[ Route-Record ] 

5.3.2.5 Alert-Service-Centre-Request (ALR) Command 

The Alert-Service-Centre-Request (ALR) command, indicated by the Command-Code field set to 8388648 and the "R" 
bit set in the Command Flags field, is sent from SMS-GMSC or IP-SM-GW to HSS. 

Message Format: 

< Alert-Service-Centre-Request > ::= < Diameter Header: 8388648, REQ, PXY, 16777312 > 

< Session-Id > 

[ Vendor-Specific-Application-Id ] 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 

[ Destination-Host ] 

{ Destination-Realm } 

{ SC-Address } 

{ User-Identifier } 

*[ Supported-Features ] 

*[ AVP ] 

*[ Proxy-Info ] 

*[ Route-Record ] 

5.3.2.6 Alert-Service-Centre-Answer (ALA) Command 

The Alert-Service-Centre-Answer (ALA) command, indicated by the Command-Code field set to 8388648 and the 'R' 
bit cleared in the Command Flags field, is sent from HSS to SMS-GMSC or IP-SM-GW. 

Message Format 

< Alert-Service-Centre- Answer > ::= < Diameter Header: 8388648, PXY, 16777312 > 

< Session-Id > 
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[ Vendor-Specific-Application-Id ] 

[ Result-Code ] 

[ Experimental-Result ] 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 

*[ Supported-Features ] 

*[ AVP ] 

*[ Failed- AVP ] 

*[ Proxy-Info ] 

*[ Route-Record ] 

5.3.2.7 Report-SM-Delivery-Status-Request (RDR) Command 

The Report-SM-Delivery-Status-Request (RDR) command, indicated by the Command-Code field set to 8388649 and 
the "R" bit set in the Command Flags field, is sent from SMS-GMSC or IP-SM-GW to HSS. 

Message Format: 

< Report-SM-Delivery-Status-Request > ::= < Diameter Header: 8388649, REQ, PXY, 16777312 > 

< Session-Id > 

[ Vendor-Specific-Application-Id ] 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 

[ Destination-Host ] 

{ Destination-Realm } 

*[ Supported-Features ] 

{ User-Identifier } 

{ SC-Address } 

{ SM-Delivery-Outcome } 

*[ AVP ] 

*[ Proxy-Info ] 

*[ Route-Record ] 

5.3.2.8 Report-SM-Delivery-Status-Answer (RDA) Command 

The Report-SM-Delivery-Status-Answer (RDA) command, indicated by the Command-Code field set to 8388649 and 
the 'R' bit cleared in the Command Flags field, is sent from HSS to SMS-GMSC or IP-SM-GW. 

Message Format 

< Report-SM-Delivery-Status-Answer > ::= < Diameter Header: 8388649, PXY, 16777312 > 

< Session-Id > 

[ Vendor-Specific-Application-Id ] 

[ Result-Code ] 

[ Experimental-Result ] 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 

*[ Supported-Features ] 

[ User-Identifier ] 

*[ AVP ] 

*[ Failed- AVP ] 

*[ Proxy-Info ] 

*[ Route-Record ] 
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5.3.3 AVPs 



5.3.3.1 



General 



The following table specifies the Diameter AVPs defined for the S6c interface protocol, their AVP Code values, types, 
possible flag values and whether or not the AVP may be encrypted. The Vendor-ID header of all AVPs defined in this 
specification shall be set to 3GPP (10415). 

For all AVPs which contain bit masks and are of the type Unsigned32, e.g. TFR-Flags, bit shall be the least significant 
bit. For example, to get the value of bit 0, a bit mask of 0x0001 should be used. 

Table 5.3.3.1/1 : S6c specific Diameter AVPs 





AVP Flag rules 




Attribute Name 


AVP 
Code 


Section 
defined 


Value Type 


Must 


May 


Should not 


Must 
not 


May 
Encr. 


SM-RP-MTI 


3308 


5.3.3.2 


Enumerated 


M, V 








No 


SM-RP-SMEA 


3309 


5.3.3.3 


OctetString 


M, V 








No 


SRR-Flags 


3310 


5.3.3.4 


Unsigned32 


M, V 








No 


SM-Delivery-Not-lntended 


3311 


5.3.3.5 


Enumerated 


M, V 








No 


MWD-Status 


3312 


5.3.3.8 


Unsigned32 


M, V 








No 


MME-Absent-User- 
Diagnostic-SM 


3313 


5.3.3.9 


Enumerated 


M, V 








No 


MSC-Absent-User- 
Diagnostic-SM 


3314 


5.3.3.10 


Enumerated 


M, V 








No 


SGSN-Absent-User- 
Diagnostic SM 


3315 


5.3.3.11 


Enumerated 


M, V 








No 


SM-Delivery-Outcome 


3316 


5.3.3.14 


Grouped 


M, V 








No 


MME-SM-Delivery- 
Outcome 


3317 


5.3.3.15 


Grouped 


M, V 








No 


MSC-SM-Delivery- 
Outcome 


3318 


5.3.3.16 


Grouped 


M, V 








No 


SGSN-SM-Delivery- 
Outcome 


3319 


5.3.3.17 


Grouped 


M, V 








No 


IP-SM-GW-SM-Delivery- 
Outcome 


3320 


5.3.3.18 


Grouped 


M, V 








No 


SM-Delivery-Cause 


3321 


5.3.3.19 


Enumerated 


M, V 








No 


Absent-User-Diagnostic- 
SM 


3322 


5.3.3.20 


OctetString 


M, V 








No 


NOTE 1 : The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header bit 

denoted as "V" indicates whether the optional Vendor-ID field is present in the AVP header. For further details, 
see IETF RFC 3588 [4]. 

NOTE 2: If the IVI-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M- 
bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the 
receiver understands the AVP but the IVI-bit value does not match with the definition in this table, the receiver 
shall ignore the M-bit. 



The following table specifies the Diameter AVPs re-used from existing Diameter Applications, including a reference to 
their respective specifications and when needed, a short description of their use within this interface. 

Any other AVPs from existing Diameter Applications, except for the AVPs from Diameter Base Protocol, do not need 
to be supported. The AVPs from Diameter Base Protocol are not included in table 5.3.3.1/2, but they may be re-used for 
this interface. 
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Table 5.3.3.1/2: S6c re-used Diameter AVPs 



Attribute 
Name 


Reference 


Comments 


M-bit 


User-Name 


IETF RFC 3588 [7] 




Must 


MSISDN 


3GPPTS 23.329 [14] 






SC-Address 


3GPP TS 29.338 


It is defined for the SGd interface, see subclause 6.3.3.2 




LMSI 


3GPPTS 29.173 [10] 






Serving-Node 


3GPPTS 29.173 [10] 


See subclause 5.3.3.6 




MSC-Number 


3GPPTS 29.173 [10] 






MME-Name 


3GPPTS 29.173 [10] 






MME-Realm 


3GPPTS 29.173 [10] 




Must 


MME-Number- 
for-MT-SMS 


3GPP TS 29.272 [4] 




Must 


SGSN-Number 


3GPP TS 29.272 [4] 






Additional- 
Serving-Node 


3GPPTS 29.173 [10] 


See subclause 5.3.3.7 




User-Identifier 


3GPPTS 29.336 [15] 






SIVI-Delivery- 
Failure-Cause 


3GPP TS 29.338 


It is defined for the SGd interface, see subclause 6.3.3.5 




IP-SM-GW- 
Name 


3GPPTS 29.336 [15] 






IP-SM-GW- 
Number 


3GPPTS 29.336 [15] 






Supported- 
Features 


3GPP TS 29.229 [5] 






Feature-List-ID 


3GPP TS 29.229 [5] 


See subclause 5.3.3.12 




Feature-List 


3GPP TS 29.229 [5] 


See subclause 5.3.3.13 




NOTE 1 : The IVI-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values 
include: "Must set", "Must not set". If the M-bit setting is blank, then the defining specification applies. 

NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M- 
bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the 
receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver 
shall ignore the M-bit. 



5.3.3.2 



SM-RP-MTI 



The SM-RP-MTI AVP is of type Enumerated and shall contain the RP-Message Type Indicator of the Short Message. 
The following values are defined: 

- SM_DELIVER (0) 

- SM_STATUS_REPORT (1) 



5.3.3.3 



SM-RP-SMEA 



The SM-RP-SMEA AVP is of type OctetString and shall contain the RP-Originating SME-address of the Short 
Message Entity that has originated the SM. It shall be formatted according to the formatting rules of the address fields 
described in 3GPP TS 23.040 [3]. 



5.3.3.4 



SRR-Flags 



The SRR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined 
intable5.3.3.4./l: 
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Table 5.3.3.4/1 : SRR-Flags 



Bit 


Name 


Description 





GPRS-Indicator 


This bit shall be set if the SIVIS-GMSC supports receiving of two 
serving nodes addresses from the HSS. 


1 


SM-RP-PRI 


This bit shall be set if the delivery of the short message shall be 
attempted when a service centre address is already contained in 
the Message Waiting Data file 


NOTE 1 : Bits not defined in this table shall be cleared by the sending entity and discarded by the 
receiving entity. 



5.3.3.5 SM-Delivery-Not-lntended 

The SM-Delivery-Not-Intended AVP is of type Enumerated and shall indicate by its presence that delivery of a short 
message is not intended. It further indicates whether only IMSI or only MCC+MNC with the following values: 

- ONLY_IMSI_REQUESTED (0), 

- ONLY_MCC_MNC_REQUESTED (1). 

5.3.3.6 Serving-Node 

The Serving-Node AVP is of type Grouped. This AVP shall contain the information about the network node serving the 
targeted user. It is originally defined in 3GPP TS 29.173 [10]. 

AVP format 

Serving-Node ::=< AVP header: 2401 10415> 

[ SGSN-Number ] 

[ MME-Name ] 

[ MME-Realm ] 

[ MME-Number-for-MT-SMS ] 

[ MSC-Number ] 

[ IP-SM-GW-Number ] 

[ IP-SM-GW-Name ] 

*[AVP] 
The following combinations are allowed: 

a) SGSN-Number 

b) MME-Name & MME-Realm & MME-Number-for-MT-SMS 

c) MSC-Number 

d) MSC-Number & MME-Name & MME-Realm 

e) IP-SM-GW-Number 

f) IP-SM-GW-Number & IP-SM-GW-Name. 



5.3.3.7 



Additional-Serving-Node 



The Additional-Serving-Node AVP is of type Grouped. This AVP shall contain the information about the network node 
serving the targeted user. It is originally defined in 3GPP TS 29.173 [10]. 

AVP format 
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Additional-Serving-Node ::= <AVP header: 2406 10415> 
[ SGSN-Number ] 
[ MME-Name ] 
[ MME-Realm ] 

[ MME-Number-for-MT-SMS ] 
[ MSC-Number ] 
*[AVP] 
The following combinations are allowed: 

a) SGSN-Number 

b) MME-Name & MME-Realm & MME-Number-for-MT-SMS 

c) MSC-Number 

d) MSC-Number & MME-Name & MME-Realm 



5.3.3.8 



MWD-Status 



The MWD-Status AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as 
defined in table 5.3.3.8/1: 

Table 5.3.3.8/1 : MWD Status 



bit 


name 


Description 





SC-Address Not 
included 


This bit when set shall indicate the presence of the SC Address 
in the Message Waiting Data in the HSS. 


1 


MNRF-Set 


This bit, when set, shall indicate that the MNRF flag is set in the 
HSS 


2 


MCEF-Set 


This bit, when set, shall indicate that the IVICEF flag is set in the 
HSS. 


3 


MNRG-Set 


This bit, when set, shall indicate that the MNRG flag is set in the 
HSS 


NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the 
receiving IVIME. 



5.3.3.9 



MME-Absent-User-Diagnostic-SM 



The MME-Absent-User-Diagnostic-SM AVP is of type Enumerated and shall indicate the diagnostic explaining the 
absence of the user given by the MME. The values are defined in 3GPP TS 23.040 [3]. 

5.3.3.1 MSC-Absent-User-Diagnostic-SM 

The MSC-Absent-User-Diagnostic-SM AVP is of type Enumerated and shall indicate the diagnostic explaining the 
absence of the user given by the MSC. The values are defined in 3GPP TS 23.040 [3]. 

5.3.3.1 1 SGSN-Absent-Subscriber-Diagnostic-SM 

The SGSN-Absent-User-Diagnostic-SM AVP is of type Enumerated and shall indicate the diagnostic explaining the 
absence of the user given by the SGSN. The values are defined in 3GPP TS 23.040 [3]. 



5.3.3.12 



Feature-List-ID AVP 



The syntax of this AVP is defined in 3GPP TS 29.229 [5]. For this release, the Feature-List-ID AVP value shall be set 
tol. 



£75/ 



3GPP TS 29.338 version 1 1 .0.0 Release 1 1 26 ETSI TS 1 29 338 V1 1 .0.0 (201 3-01 ) 

5.3.3.13 Feature-List AVP 

The syntax of this AVP is defined in 3GPP TS 29.229 [5]. A null value indicates that there is no feature used by the 
application. 

NOTE: There is no feature defined for this release. 

5.3.3.14 SM-Delivery-Outcome 

The SM-Delivery-Outcome AVP is of type Grouped. This AVP contains the result of the SM delivery. 
AVP format: 

SM-Delivery-Outcome::=<AVP header: 3316 10415> 

[ MME-SM-Delivery-Outcome ] 

[ MSC-SM-Delivery-Outcome ] 

[ SGSN-SM-Delivery-Outcome ] 

[ IP-SM-GW-SM-Delivery-Outcome] 

*[AVP] 

5.3.3.15 MME-SM-Delivery-Outcome 

The MME-Delivery-Outcome AVP is of type grouped and shall indicate the outcome of the SM delivery for setting the 
message waiting data in the HSS when the SM delivery is with an MME. 

AVP format: 

MME-SM-Delivery-Outcome: := <AVP header: 3317 10415» 

[ SM-Delivery-Cause ] 

[ Absent-User-Diagnostic-SM ] 

5.3.3.16 MSC-SM-Delivery-Outcome 

The MSC-Delivery-Outcome AVP is of type grouped and shall indicate the outcome of the SM delivery for setting the 
message waiting data in the HSS when the SM delivery is with an MSC. 

AVP format: 

MSC-SM-Delivery-Outcome: :=<AVP header: 3318 10415> 

[ SM-Delivery-Cause ] 

[ Absent-User-Diagnostic-SM ] 

5.3.3.17 SGSN-SM-Delivery-Outcome 

The MSC-MME-Delivery-Outcome AVP is of type grouped and shall indicate the outcome of the SM delivery for 
setting the message waiting data in the HSS when the SM delivery is with an SGSN. 

AVP format: 

SGSN-SM-Delivery-Outcome::= <AVP header: 3319 10415> 

[ SM-Delivery-Cause ] 

[ Absent-User-Diagnostic-SM ] 
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5.3.3.1 8 IP-SM-GW-SM-Delivery-Outcome 

The IP"SM-GW-SM-Delivery-Outcome AVP is of type grouped and shall indicate the outcome of the SM delivery for 
setting the message waiting data when the SM delivery is with an IP-SM_GW. The following values are defined. 

AVP format: 

IP-SM-GW-SM-Delivery-Outcome: := <AVP header: 3320 10415> 

[ SM-Delivery-Cause ] 

[ Absent-User-Diagnostic-SM ] 

5.3.3.19 SM-Delivery-Cause 

The SM-Delivery-Cause AVP is of type Enumerated and shall indicate the cause of the SMP delivery result. The 
following values are defined: 

- UE_ MEMORY_CAPACITY_EXCEEDED (0) 

- ABSENT_USER(1) 

- SUCCESSFUL_TRANSFER (2) 

5.3.3.20 Absent-Subscriber-Diagnostic-SM 

The Absent-Subscriber-Diagnostic-SM AVP is of type Integer32 and shall indicate the diagnostic explaining the 
absence of the subscriber. The values are defined in 3GPP TS 23.040 [3]. 

5.4 User identity to HSS resolution 

The User identity to HSS resolution mechanism enables the SMS-GMSC or SMS Router in the home PLMN or 
Diameter proxy agents in the home PLMN to find the identity of the HSS that holds the subscriber data for a given user 
identified by its MSISDN or by its IMSI when multiple and separately addressable HSSs have been deployed in the 
home PLMN. The resolution mechanism is not required in PLMNs that utilise a single HSS. 

This User identity to HSS resolution mechanism may rely on routing capabilities provided by Diameter and be 
implemented in the home PLMN within dedicated Diameter Agents (Proxy Agents) responsible for determining the 
HSS identity based on the provided user identity. If this Diameter based implementation is selected by the home PLMN 
operator, the principles described below shall apply. 

When more than one independently addressable HSS are deployed in the home PLMN, each SMS-GMSC or SMS- 
Router network of the home PLMN shall be configured with the address/identity of a Diameter Agent (Proxy Agent) 
implementing this resolution mechanism. 

Diameter Relay agents and/or Diameter Proxy agents in the home PLMN receiving the Diameter signalling from SMS- 
GMSC located in other PLMNs shall be configured with the address/identity of a Diameter Agent (Proxy Agent) 
implementing this resolution mechanism. 

To get the HSS identity that holds the subscriber data for a given user identity in the home network, the Diameter 
request normally destined to the HSS shall be sent to the pre-configured address/identity of a Diameter Proxy agent 
supporting the User identity to HSS resolution mechanism. 

If this Diameter request is received by a Diameter Redirect Agent, the Diameter Redirect Agent shall determine 
the HSS identity based on the provided user identity (i.e. MSISDN or IMSI) and shall return a notification of 
redirection towards the HSS identity, in response to the Diameter request. Multiple HSS identities may be 
included in the response, as specified in IETF RFC 3588 [4]. In such a case, the requesting Diameter entity shall 
send the Diameter request to the first HSS identity in the ordered list received in the Diameter response from the 
Diameter Redirect Agent. If no successful response to the Diameter request is received, the requesting Diameter 
entity shall send a Diameter request to the next HSS identity in the ordered list. This procedure shall be repeated 
until a successful response from an HSS is received. After the user identity to HSS resolution, the MME or the 
SGSN shall store the determined HSS identity/name/Realm and shall use it in further Diameter requests to the 
same user identity. 
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If this Diameter request is received by a Diameter Proxy Agent, the Diameter Proxy Agent shall determine the 
HSS identity based on the provided user identity (i.e. MSISDN or IMSI) and shall forward the Diameter request 
directly to the HSS. In this case, the user identity to HSS resolution decision is communicated to the SMS- 
GMSC in the Origin-Host/Origin-Realm AVPs of the response. 

NOTE: Alternatives to the user identity to HSS resolution Diameter based implementation are outside the scope 
of this specification. 



Diameter based SGd interface between IVIIVIE and 
central SIVIS functions 



6.1 



Introduction 



The SGd interface enables the transfer of short messages between the MME, the SMS-IWMSC, the SMS-GMSC and 
the SMS Router as described in 3GPP TS 23.040 [3]. 

6.2 Procedures description 

6.2.1 MO Forward Short Message procedure 



6.2.1.1 



General 



This procedure shall be used between the serving MME and the SMS-IWMSC to forward mobile originated short 
messages from a mobile user to a Service Centre. 

This procedure is used according to the call flows described in 3GPP TS 23.040 [3] clause 10. 

Table 6.2.1.1/1 specifies the involved information elements for the request. 

Table 6.2.1.1/2 specifies the involved information elements for the answer. 

This procedure is mapped to the commands MO-Forward-Short-Message-Request/ Answer (OFR/OFA) in the Diameter 
application specified in subclause 6.3.2. 

Table 6.2.1.1/1 : MO Forward Short Message Request 



Information 

element 

name 


Mapping to 
Diameter AVP 


Cat. 


Description 


SM RP DA 


SC-Address 


M 


This information element shall contain the Service Centre address 
received from the mobile station. 


SM RP OA 


User-Identifier 


M 


This information element shall contain: 

-thellVISI 

- the MSISDN of the user when it exists. 


SM RP Ul 


SM-RP-UI 


M 


This information element shall contain the short message transfer protocol 
data unit 


Supported 
Features 


Supported- 
Features 





If present, this information element shall contain the list of features 
supported by the origin host. 
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Table 6.2.1.1/2: MO-Forward Short Message Answer 



Information 

element 

name 


Mapping to 
Diameter AVP 


Cat 


Description 


Result 


Result-Code / 
Experimental- 
Result 


M 


This information element shall contain the result of the operation. 

The Result-Code AVP shall be used to indicate success / errors as defined 

in the Diameter Base Protocol. 

The Experimental-Result AVP shall be used for SGd errors. This is a 

grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id 

AVP, and the error code in the Experimental-Result-Code AVP. The 

following errors are applicable: 

Facility Not Supported; 

SIVl Delivery Failure. 


SM Delivery 
Failure Cause 


SM-Delivery- 
Failure-Cause 


C 


If the Experimental-Result-Code is set to 

DIAMETER_ERROR_SM_DELIVERY_FAILURE, this information element 
shall be present and indicate one of the following: 

unknown Service Centre address; 

Service Centre congestion; 

invalid Short IVIessage Entity address; 

user not Service Centre user. 
It may be completed with a Diagnostic information element. 


SMRPUI 


SM-RP-UI 





If present, this information element shall contain a short message transfer 
protocol data unit in the message delivery acknowledgement from the 
SMS-IWMSC to the MME 


Supported 
Features 


Supported- 
Features 





If present, this information element shall contain the list of features 
supported by the origin host. 



6.2.1.2 



Detailed behaviour of the MME 



When the "SMS in MME" feature is applied for the UE, the MME shall make use of this procedure to forward mobile 
originated short messages received from the UE to the SMS-IWMSC associated to the SMS-SC indicated by the UE. 
The MME shall check if the SMS related subscription data (e.g. ODB data and Call Barring) allows forwarding the 
short message. 



6.2.1.3 



Detailed behaviour of the SMS-IWMSC 



When receiving the MO Forward Short Message Request, the SMS-IWMSC shall check if the SMS-SC is known, if it 
is not, an Experimental-Result-Code set to DIAMETER_ERROR_SM_DELIVERY_FAILURE and a SM Delivery 
Failure Cause indicating "unknown Service Centre address" shall be returned to the MME. 

The SMS IWMSC shall then pass the short message to the addressed SMS-SC. 

If the SMS-SC returns a negative acknowledgement, an Experimental-Result-Code set to 

DIAMETER_ERROR_SM_DELIVERY_FAILURE and a SM Delivery Failure Cause indicating the cause given by the 
SMC-SC shall be returned to the MME. 

If the SMS-SC returns a positive acknowledgement to the SMS IWMSC, a Result-Code set to DIAMETER_SUCCESS 
shall be returned to the MME. 

If a requested facility is not supported, an Experimental-Result-Code set to 
DIAMETER_ERROR_FACILITY_NOT_SUPPORTED shall be returned. 

6.2.2 MT Forward Short Message procedure 



6.2.2.1 



General 



This procedure shall be used between the G-MSC and the serving MME (transiting an SMS Router, if present) to 
forward mobile terminated short messages. 

This procedure is used according to the call flows described in 3GPP TS 23.040 [3] clause 10. 
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Table 6.2.2.1/1 specifies the involved information elements for the request. 

Table 6.2.2.1/2 specifies the involved information elements for the answer. 

This procedure is mapped to the commands MT-Forward-Short-Message-Request/ Answer (TFR/TFA) in the Diameter 
application specified in subclause 6.3.2. 

Table 6.2.2.1/1 : MT Forward Short Message Request 



Information 
element name 


Mapping to 
Diameter AVP 


Cat. 


Description 


SM RP DA 


User-Name 
(See IETF 
RFC 3588 [6]) 


M 


This information element shall contain an IMS! 


SM RP OA 


SC-Address 


M 


This information element shall contain the Service Centre address. 


SM RP Ul 


SM-RP-UI 


M 


This information element shall contain the short message transfer protocol 
data unit. 


MME Number 
for MT SMS 


MME-Number- 
for-MT-SMS 


M 


This Information Element contains the ISDN number of the MME, see 
3GPP TS 23.003 [3]. 


TFR-Flags 


TFR-Flags 


C 


This information element shall contain a bit mask. Bit indicates when set 
if the Service Centre has more messages to send 


SM Delivery 
Timer 


SM-Delivery- 
Timer 





This information element, when present, shall indicate the SM Delivery 
Timer value set in the SMS-GMSC to the IP-SM-GW. 


SM Delivery 
Start Time 


SM-Delivery- 
Start-Time 





This information element, when present, shall indicate the timestamp (in 
UTC) at which the SM Delivery Supervision Timer was started in the SMS- 
GMSC. 


Supported 
Features 


Supported- 
Features 
(See 3GPP TS 
29.229 [5]) 





If present, this information element shall contain the list of features 
supported by the origin host. 
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Table 6.2.2.1/2: MT Forward Short Message Answer 



Information 
element name 


Mapping to 
Diameter AVP 


Cat. 


Description 


Result 


Result-Code / 
Experimental- 
Result 


M 


This information element shall contain the result of the operation. 
The Result-Code AVP shall be used to indicate success / errors as 
defined in the Diameter Base Protocol. 

The Experimental-Result AVP shall be used for SGd errors. This is a 
grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id 
AVP, and the error code in the Experimental-Result-Code AVP. The 
following errors are applicable: 

Unknown User; 

Absent User; 

User busy for MT SMS; 

Illegal User; 

Illegal Equipment; 

SM Delivery Failure. 


Absent User 
Diagnostic SM 


Absent-User- 
Diagnostic-SM 





This information element may be present when Experimental-Result-Code 
is set to DIAMETER_ERROR_ABSENT_USER and it shall contain the 
reason of the absence of the user given by the MME. 


SM Delivery 
Failure Cause 


SM-Delivery- 
Failure-Cause 


C 


If Experimental-Result-Code is set to 

DIAMETER_ERROR_SM_DELIVERY_FAILURE, this information element 
shall be present and indicate one of the following: 

memory capacity exceeded in the mobile equipment; 

UE error; 

mobile equipment not equipped to support the mobile terminated 

short message service. 
It may be completed with a Diagnostic information element 


SMRPUI 


SM-RP-UI 





If present, this information element shall contain a short message transfer 
protocol data unit in the message delivery acknowledgement from the 
MME to the Service Centre. 


Supported 
Features 


Supported- 
Features 
(See 3GPP TS 
29.229 [5]) 





If present, this information element shall contain the list of features 
supported by the origin host. 



6.2.2.2 Detailed behaviour of the MME 

When receiving a MT Forward Short Message Request, the MME shall check if the IMSI is known, 

If it is not known, an Experimental-Result-Code set to DIAMETER_ERROR_USER_UNKNOWN shall be returned. 

The MME shall attempt to deliver the short message to the UE. 

If the delivery of the short message to the UE is successful, the MME shall return a Result-Code set to 
DI AMETER_S UCCES S . 

If the UE is not reachable, the MME shall set the MNRF flag and shall return an Experimental-Result-Code set to 
DIAMETER_ERROR_ ABSENT_USER. 

If the delivery of the mobile terminated short message failed because of memory capacity exceeded or UE error or UE 
not SM equipped, the MME shall return an Experimental-Result-Code set to 
DIAMETER_ERROR_SM_DELIVERY_FAILURE complemented with a SM Delivery Failure Cause indication. 

If a requested facility is not supported, the MME shall return an Experimental-Result-Code set to 
DIAMETER_ERROR_FACILITY_NOT_SUPPORTED. 

If the user is busy for MT SMS, i.e. the mobile terminated short message transfer cannot be completed because: 

another mobile terminated short message transfer is going on and the delivery node does not support 
message buffering; or 

another mobile terminated short message transfer is going on and it is not possible to buffer the message 
for later delivery; or 
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the message was buffered but it is not possible to deliver the message before the expiry of the buffering 
time defined in 3GPP TS 23.040 [3], 

the MME shall return an Experimental-Result-Code set to DIAMETER_ERROR_USER_BUSY_FOR_MT_SMS. 

If the delivery of the mobile terminated short message failed because the mobile station failed authentication, the MME 
shall return an Experimental-Result-Code set to DIAMETER_ERROR_ILLEGAL_USER. 

If the delivery of the mobile terminated short message failed because an IMEI check failed, i.e. the IMEI was 
blacklisted or not white-listed, the MME shall return an Experimental-Result-Code set to 
DIAMETER_ERROR_ILLEGAL_EQUIPMENT. 

6.2.2.3 Detailed behaviour of the SMS-GMSC 

The SMS-GMSC shall make use of this procedure over the SGd interface for the delivery of a MT short message when 
it has selected the serving node of which it obtained the Diameter Identity from the answer of the Send Routing Info for 
SM procedure. 

NOTE: The SMS-GMSC is not aware that the MT Forward Short Message Request may be routed to a SMS 
router. 

6.2.2.4 Detailed behaviour of the SMS-Router 

When the SMS router has received a MT Forward Short Message from the SMS-GMSC and the SMS Router has 
selected the MME for dehvery, the SMS Router shall forward it to the MME. 

When a MT Forward Short Message Answer is received from the MME, the SMS Router shall forward it to the SMS- 
GMSC. 

6.3 Protocol specification 

6.3.1 Routing considerations 

6.3.1 .1 Routing for MO Forward SM messages: 

This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host over the SGd 
interface for the Diameter command requests from the MME (i.e. for the MO forward SM procedure). 

If the MME, from the SMS-SC E164 number received from the UE, can obtain the address/name of the SMS-IWMSC 
and the associated home network domain name (e.g. by local configuration), both the Destination-Realm and 
Destination-Host AVPs shall be present in the request. 

If the MME, from the SMS-SC E164 number received from the UE, can only obtain the MCC/MNC values of the 
PLMN to which the SMS-SC belongs, the MME shall use them to build the MCC/MNC based network domain as 
described in subclause 19.2 of 3GPP TS 23.003 [16] and include it in the Destination-Realm AVP of the request. The 
request shall then be routed to the next Diameter node. 

If the MME cannot obtain the MCC/MNC values from the SMS-SC E164 number, the MME shall forward the request 
to a Diameter node within the same PLMN, the Destination Realm content being left to the PLMN operator choice. 
Then: 

if a Diameter node in the routing path insides the PLMN of the MME can obtain the MCC/MNC values of the 
PLMN to which the SMS-SC belongs, 

it shall use them to build the MCC/MNC based network domain as described in subclause 19.2 of 3GPP TS 
23.003 [16] and include it in the Destination-Realm AVP of the request. The request shall then be routed to the 
next Diameter node. 

If the MCC/MNC values of the PLMN to which the SMS-SC belongs cannot be obtained in the PLMN of the MME, the 
request shall be replaced in the PLMN of the SMS-GMSC by an equivalent request routed through a MAP interface 
(e.g. via an IWF). 
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NOTE 1 : The inter PLMN routing principle is to reuse the routing based on a MCC/MNC based domain name as 
used by other Diameter appHcations such as S6a/d. It is assumed that obtaining the relevant MCC/MNC 
values from the E164 number of the SMS-SC can be achieved in the PLMN which the MME belongs to. 
Otherwise a MAP based routing is used. This routing principle may be completed with other routing 
solutions in the future. 

Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by an MME. 



6.3.1.2 



Routing for MT Forward SM messages: 



This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host for the Diameter 
command requests from the SMS-GMSC or the SMS Router (i.e. for the MT forward SM procedure). 

if the SMS-GMSC has received the Diameter address/name of an MME in the answer to its interrogation to the 
HSS/HLR for retrieving routing information and if it selects this serving node, it shall use it to populate the 
Destination-Realm and Destination-Host AVPs. 

If the SMS Router has received the Diameter address/name of the MME in the answer to its interrogation to the 
HSS/HLR for retrieving routing information and if it selects this serving node, it shall use this Diameter 
address/name to populate the Destination-Realm and Destination-Host AVPs. 

Consequently, the Destination-Host AVP is declared as mandatory in the ABNF for all requests initiated by an SMS- 
GMSC or a SMS router. 

6.3.2 Commands 
6.3.2.1 Introduction 

This section defines the Command code values and related ABNF for each command described for the SGd interface. 



6.3.2.2 



Command-Code values 



This section defines the Command-Code values for the SGd interface application as allocated by lANA in the IETF 
RFC 5516 [8]. 

Every command is defined by means of the ABNF syntax IETF RFC 2234 [6], according to the rules in IETF RFC 
3588 [7]. In the case, the definition and use of an AVP is not specified in this document, the guidelines in IETF RFC 
3588 [7] shall apply. 

NOTE: For this release, the Vendor-Specific-Application-ID is included as an optional AVP in all commands in 
order to ensure interoperability with diameter agents following a strict implementation of IETF RFC 3588 
[7], by which messages not including this AVP will be rejected. IETF RFC 3588 [7] indicates that the 
AVP shall be present in all proxiable commands, such as those specified here, despite that the contents of 
this AVP are redundant since the Application ID is already present in the command header. This AVP 
may be removed in subsequent revisions of this specification, once the diameter base protocol is updated 
accordingly. 

The following Command Codes are defined in this specification: 

Table 6.3.2.2/1 : Command-Code values for SGd 



Command-Name 


Abbreviation 


Code 


Section 


MO-Forward-Short-Message Request 


OFR 


8388645 


6.3.2.3 


MO-Forward-Short-Message Answer 


OFA 


8388645 


6.3.2.4 


MT-Forward-Short-Message Request 


TFR 


8388646 


6.3.2.5 


MT-Forward-Short-Message Answer 


TFA 


8388646 


6.3.2.6 



For these commands, the Application-ID field shall be set to 16777313 (application identifier of the SGd interface 
application, allocated by lANA). 
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6.3.2.3 MO-Forward-Short-Message-Request (OFR) Command 

The MO-Forward-Short-Message-Request (OFR) command, indicated by the Command-Code field set to 8388645 and 
the "R" bit set in the Command Flags field, is sent from MME to SMS-IWMSC. 

Message Format 

< MO-Forward-Short-Message-Request > ::= < Diameter Header: 8388645, REQ, PXY, 16777313 > 

< Session-Id > 

[ Vendor-Specific-Application-Id ] 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 

[ Destination-Host ] 

{ Destination-Realm } 

{ SC-Address } 

*[ Supported-Features ] 

{ User-Identifier } 

{ SM-RP-UI } 

*[ AVP ] 

*[ Proxy-Info ] 

*[ Route-Record ] 

6.3.2.4 MO-Forward-Short-Message-Answer (OFA) Command 

The MO-Forward-Short-Message- Answer Command (OFA) command, indicated by the Command-Code field set to 
8388645 and the 'R' bit cleared in the Command Flags field, is sent from SMS-IWMSC to MME. 

Message Format 

< MO-Forward-Short-Message-Answer> ::= < Diameter Header: 8388645, PXY, 16777313 > 

< Session-Id > 

[ Vendor-Specific-Application-Id ] 

[ Result-Code ] 

[ Experimental-Result ] 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 

*[ Supported-Features ] 

[ SM-Delivery- Failure-Cause ] 

[ SM-RP-UI ] 

*[ AVP ] 

*[ Failed- AVP ] 

*[ Proxy-Info ] 

*[ Route-Record ] 

6.3.2.5 MT-Forward-Short-Message-Request (TFR) Command 

The MT-Forward-Short-Message-Request (TFR) command, indicated by the Command-Code field set to 8388646 and 
the "R" bit set in the Command Flags field, is sent from SMS-GMSC to MME (transiting an SMS Router, if present). 

Message Format 

< MT-Forward-Short-Message-Request > ::= < Diameter Header: 8388646, REQ, PXY, 16777313 > 

< Session-Id > 

[ Vendor-Specific-Application-Id ] 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 

[ Destination-Host ] 

{ Destination-Realm } 

{ User-Name } 
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*[ Supported-Features ] 

{ SC-Address } 

{ SM-RP-UI } 

[ MME-Number-for-MT-SMS ] 

[ TFR-Flags ] 

[ SM-Delivery-Timer ] 

[ SM-Delivery-Start-Time ] 

*[ AVP ] 

*[ Proxy-Info ] 

*[ Route-Record ] 

6.3.2.6 MT-Forward-Short-Message-Answer (TFA) Command 

The MT-Forward-Short-Message-Answer Command (TFA) command, indicated by the Command-Code field set to 
8388646 and the 'R' bit cleared in the Command Flags field, is sent from MME to SMS-GMSC (transiting an SMS 
Router, if present). 

Message Format 

< MT-Forward-Short-Message-Answer > ::= < Diameter Header: 8388646, PXY, 16777313 > 

< Session-Id > 

[ Vendor-Specific-Application-Id ] 
[ Result-Code ] 
[ Experimental-Result ] 
{ Auth-Session-State } 
{ Origin-Host } 
{ Origin-Realm } 
*[ Supported-Features ] 
[ Absent-User-Diagnostic-SM ] 
[ SM-Delivery- Failure-Cause ] 
[ SM-RP-UI ] 
*[ AVP ] 
*[ Failed- AVP ] 
*[ Proxy-Info ] 
*[ Route-Record ] 

6.3.3 AVPs 
6.3.3.1 General 

The following table specifies the Diameter AVPs defined for the SGd interface protocol, their AVP Code values, types, 
possible flag values and whether or not the AVP may be encrypted. The Vendor-ID header of all AVPs defined in this 
specification shall be set to 3GPP (10415). 

For all AVPs which contain bit masks and are of the type Unsigned32, e.g., TFR-Flags, bit shall be the least 
significant bit. For example, to get the value of bit 0, a bit mask of 0x0001 should be used. 
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Table 6.3.3.1/1 : SGd specific Diameter AVPs 





AVP Flag rules 




Attribute Name 


AVP 
Code 


Section 
defined 


Value Type 


Must 


May 


Should not 


Must 
not 


May 
Encr. 


SC-Address 


3300 


6.3.3.2 


OctetString 


M, V 








No 


SM-RP-UI 


3301 


6.3.3.3 


OctetString 


M, V 








No 


TFR-Flags 


3302 


6.3.3.4 


Unsigned32 


M, V 








No 


SM-Delivery- Failure-Cause 


3303 


6.3.3.5 


Grouped 


M, V 








No 


SM-Enumerated-Delivery- 
Failure-Cause 


3304 


6.3.3.6 


Enumerated 


M, V 








No 


SM-Diagnostic-lnfo 


3305 


6.3.3.7 


OctetString 


M, V 








No 


SM-Delivery-Timer 


3306 


6.3.3.10 


Unsigned32 


M, V 








No 


SM-Delivery-Start-Time 


3307 


6.3.3.11 


Time 


M, V 








No 


NOTE 1 : The AVP header bit denoted as "IVI", indicates whether support of the AVP is required. The AVP header bit 

denoted as "V" indicates whether the optional Vendor-ID field is present in the AVP header. For further details, 
see IETF RFC 3588 [4]. 

NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M- 
bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the 
receiver understands the AVP but the IVI-bit value does not match with the definition in this table, the receiver 
shall ignore the IVI-bit. 



The following table specifies the Diameter AVPs re-used from existing Diameter Applications, including a reference to 
their respective specifications and when needed, a short description of their use within this interface. 

Any other AVPs from existing Diameter Applications, except for the AVPs from Diameter Base Protocol, do not need 
to be supported. The AVPs from Diameter Base Protocol are not included in table 6.3.3. 1/2, but they may be re-used for 
this interface. 

Table 6.3.3.1/2: SGd re-used Diameter AVPs 



Attribute Name 


Reference 


Comments 


M-bit 


User-Name 


IETF RFC 
3588 [7] 




Must 


User-Identifier 


3GPPTS 
29.336 [15] 






I\/1ME-Number- 
for-MT-SMS 


3GPP TS 
29.272 [4] 






Absent-User- 
Diagnostic-SIVI 


3GPP TS 
29.338 


It is defined for the S6c interface, see subclause 5.3.3.20 




Supported- 
Features 


3GPP TS 
29.229 [5] 






Feature-List-ID 


3GPP TS 
29.229 [5] 


See subclause 6.3.3.8 




Feature-List 


3GPP TS 
29.229 [5] 


See subclause 6.3.3.9 




NOTE 1 : The IVI-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values 
include: "Must set", "Must not set". If the M-bit setting is blank, then the defining specification applies. 

NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M- 
bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the 
receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver 
shall ignore the M-bit. 



6.3.3.2 



SC-Address 



The SC-Address AVP is of type UTFSString and it shall contain the E164 number of the SMS-SC, in international 
number format as described in ITU-T Recommendation E.164 [13]. 



6.3.3.3 



SM-RP-UI 



The SM-RP-UI is of type OctetString and it shall contain a short message transfer protocol data unit (TPDU) which is 
defined in 3GPP TS 23.040 [3] and represents the user data field carried by the short message service relay sub-layer 
protocol. Its maximum length is of 200 octets. 
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6.3.3.4 TFR-Flags 

The TFR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined 
in table 6.3.3.4/1: 

Table 6.3.3.4/1 : TFR-Flags 



Bit 


Name 


Description 





More-Messages-To- 
Send 


This bit, when set, shall indicate that the service centre has more 
short messages to send. 


NOTE 1 : Bits not defined in this table shall be cleared by the sending entity and discarded by the 
receiving entity. 



6.3.3.5 SM-Delivery-Failure-Cause 

The SM-Delivery-Failure-Cause AVP is of type Grouped. It shall contain information about the cause of the failure of a 
SM delivery with an optional Diagnostic information. 

The AVP format shall conform to: 

SM-Delivery-Failure-Cause ::= <AVP header: 3304 10415> 

{ SM-Enumerated-Delivery-Failure-Cause } 

[ SM-Diagnostic-Info ] 

*[ AVP ] 

6.3.3.6 SM-Enumerated-Delivery-Failure-Cause 

The SM-Enumerated-Delivery-Failure-Cause AVP is of type enumerated and it shall contain the cause of the failure of 
a SM delivery. The following values are defined: 

MEMORY_CAPACITY_EXCEEDED (0), 

EQUIPMENT_PROTOCOL_ERROR (1), 

EQUIPMENT_NOT_SM-EQUIPPED (2), 

UNKNOWN_SERVICE_CENTRE (3), 

SC-CONGESTION (4), 

INVALID_SME-ADDRESS (5), 

USER_NOT_SC-USER (6). 

NOTE: The values of the SM- Enumerated-Delivery-Failure-Cause AVP correspond to the ones for the SM- 
EnumeratedDeliveryFailureCause parameter in MAP as described in 3GPP TS 29.002[9]. 

6.3.3.7 SM-Diagnostic-Info 

The SM-Diagnostic-Info AVP is of type OctetString and it shall contain a complementary information associated to the 
SM Delivery Failure cause. 

6.3.3.8 Feature-List-ID AVP 

The syntax of this AVP is defined in 3GPP TS 29.229 [5]. For this release, the Feature-List-ID AVP value shall be set 
tol. 
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6.3.3.9 Feature-List AVP 

The syntax of this AVP is defined in 3GPP TS 29.229 [5]. A null value indicates that there is no feature used by the 
application. 

NOTE: There is no feature defined for this release. 

6.3.3.10 SM-Delivery-Timer 

The SM-Delivery-Timer is of type Integer and it shall contain the value in seconds of the timer for SM Delivery. 

6.3.3.11 SM-Delivery-Start-Time 

The SM-Delivery-Start-Time is of type Time and in shall contain the timestamp (in UTC) at which the SM Delivery 
Supervision Timer was started. 



7 Result Codes and Experimental-Result values 

7.1 General 

This section defines result code values that shall be supported by all Diameter implementations that conform to this 
specification. 

7.2 Success 

Result codes that fall within the Success category shall be used to inform a peer that a request has been successfully 
completed. The Result-Code AVP values defined in Diameter Base Protocol RFC 3588 [7] shall be applied. 

7.3 Permanent Failures 

7.3.1 General 

Errors that fall within the Permanent Failures category shall be used to inform the peer that the request has failed, and 
should not be attempted again. The Result-Code AVP values defined in Diameter Base Protocol RFC 3588 [7] shall be 
applied. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result 
AVP and the Result-Code AVP shall be absent. 

7.3.2 DIAMETER_ERROR_USER_UNKNOWN (5001 ) 

This result code shall be sent by the MME over the SGd interface to indicate that the user identified by the IMSI is 
unknown. 

This result code shall be sent by the SMS-IWMSC over the SGd interface to indicate that the user identified by the 
MSISDN is unknown. 

This result code shall be sent by the HSS or the SMS Router over the S6c interface to indicate that the user identified by 
the MSISDN is unknown. 

7.3.3 DIAMETER_ERROR_ABSENT_USER (5550) 

This result code shall be sent by the MME over the SGd interface to indicate that the UE is not reachable. 

This result code shall be sent by the HSS or the SMS Router over the S6c interface to indicate that the UE is not 
reachable. 
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7.3.4 DIAMETER_ERROR_USER_BUSY_FOR_MT_SMS (5551 ) 

This result code shall be sent by the MME when the user is busy for MT SMS. 

7.3.5 DIAMETER_ERROR_FACILITY_NOT_SUPPORTED(5552) 

This result code shall be sent to indicate a requested facility is not supported. 

NOTE: This code corresponds to the Facility Not Supported MAP error and may be used by an IWF. 

7.3.6 DIAMETER_ERRORJLLEGAL_USER (5553) 

This result code shall be sent by the MME to indicate that the delivery of the mobile terminated short message failed 
because the mobile station failed authentication. 

7.3.7 DIAMETER_ERRORJLLEGAL_EQUIPMENT (5554) 

This result code shall be sent by the MME to indicate that the delivery of the mobile terminated short message failed 
because an IMEI check failed, i.e. the IMEI was blacklisted or not white-listed. 

7.3.8 DIAMETER_ERROR_SM_DELIVERY_FAILURE (5555) 

This result code shall be sent by the MME or the SMS-IWMSC to indicate that the delivery of the mobile terminated 
short message failed. 

7.3.9 DIAMETER_ERROR_SERVICE_NOT_SUBSCRIBED(5556) 

This result code shall be sent by the HSS or the SMS Router over the S6c interface to indicate that the MT SMS 
Teleservice is not part of the subscription. 

7.3.10 DIAMETER_ERROR_SERVICE_BARRED (5557) 

This result code shall be sent by the HSS or the SMS Router over the S6c interface to indicate that the MT SMS 
Teleservice is barred. 

This result code shall be sent by the MME to indicate that the delivery of the mobile terminated short message failed 
because of the barring of the SMS service. 

7.3.1 1 DIAMETER_ERROR_MWD_LIST_FULL (5558) 

This result code shall be sent by the HSS over the S6c interface to indicate that the Message Waiting List is full. 

7.4 Transient Failures 
7.4.1 General 

Result codes that fall within the transient failures category shall be used to inform a peer that the request could not be 
satisfied at the time it was received, but may be able to satisfy the request in the future. The Result-Code AVP values 
defined in Diameter Base Protocol RFC 3588 [7] shall be applied. 
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